The next image shows how the page yosemite.html can be see with an old version of the most diffused browsers (). It contains embedded h265 video in true real time streaming, but the latest versions (Firefox after 51.0b9) do not support anymore VLC plug-ins

above the section of yosemite.html with an old version of most diffused browser. Below the most diffused browsers (such as what you're using now such as chrome, firefox, internet explorer, opera)

Original live http streaming with VLC (no more supported by current browsers)

Segmented stream in HLS generated with VLC (no more supported by current browsers)

As probably you can see, because the browsers are unable to open the stream (because they do not support anymore the VLC NPAPI plug-in) the videos simply disappears and - hopefully - you see in their place the banned VLC cone i've added as error image.

Here you can read more about the probable reason of end of support of VLC plug-in.
In the meantime VLC plug-in has been corrected and the security problem should not exist any more.
But its ban continue and browsers do not support any more plug-ins.

The following paragraph shows the playout section of the realtime streaming cell (the leftmost), i.e. no sliced at all is produced but the stream is generated by VLC as sequence of video and audio packets.

The above syntax with the usage of vlc plug-in is no more supported by current browsers, so to see a video instead of a barred cone you can use VLC recall http://www.iginomanfre.it/hls8w/hls8w.m3u8, or safari 5 for windows (latest 5.1.7 version available did it).
No chance to see the or its source http://www.iginomanfre.it/Yosemite_SD100

As told above the file http://www.iginomanfre.it/hls8/hls8.m3u8 (and the related chops) are only available in request,
while the file http://www.iginomanfre.it/hls8w/hls8w.m3u8 (and the related chops) is offline splitted and always available The m3u8 playlist can be played with VLC using open network stream (and the result):
(now replaced by hls8w)



To split permanently the file in chops I've used the following VLC call

It is hard to be done by hand: be careful to what you write, the <br> has been added to highlight the spaces

All around is moved by the profit...

hls streaming

This is the list of the hls file generated with vlc
The slices generated are pointed by the m3u8 playlist file
Due to a VLC bug (something alike a memory management) when you use VLC command-line interface at any loop is drained a little bit of memory, and this my bring the server to instability. This is particularly true in splitting, so I avoid to use the realtime splitting and production of .m3u8 files (even because only VLC can read it)

Welcome to HEVC thread

And now we must wait JVET (may 2018)

JVET stays for Joint Video Exploration Team, we must become familiar with this acronym as we did with hevc or simpler h265 few years ago.
JVET, is the next chapter the ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11 team is planning to squeeze video.
These webpages from ITU website and from Fraunhofer are maybe more detailed.

The meetings of VCEG (Video Coding Expert Group) started in october 2015, aside the Geneva Lake, when most of us just hear something of hevc.
Now, as usual, there is reference a software for the JVET group, called JEM (Joint Exploration Model) which probably let us see the stars....

The page all meetings of the JVET document management system hold by University of Sud Paris lists the documents divided by the meetings related to JVET (the rest of the site - as the draft standard - seems quite in progress): but going back of about 30 years, how many would spent a cent for mpeg?

As it is written in a paper of July 2017 but diffused in the Macau meeting :

For many applications, compression efficiency is the most important property of a future video coding standard. A substantial improvement in compression efficiency compared to HEVC Main Profile is required for the target application(s); at no point of the entire bit rate range shall it be worse than existing standard(s). 30% bitrate reduction for the same perceptual quality is sufficient for some important use-cases and may justify a future video coding standard. Other use-cases may require higher bit-rate reductions such as 50%.

We all must stay Tuned!

Darkening the welcome (january 2017)

About 20 years ago, video on the web was all but diffused as today: Youtube did not exist, but more important, to stream something it was required to produce at least three files compressed in three proprietary similar but mutually uncompatible compression schemes (quicktime, windows media and real video).

In these years we passed through flash, mpeg4, dynamic streaming, h264, DASH and last h265. Recently I've worked on the catalogue of TIM vision to address the contents to the many profiles to be compressed in h265 not exactly in cloud (it could be named how we can get all the inconveniences of cloud, as you can imagine, it's a long story, not to be dealt now).

h265 confirms an asthonishing compression scheme. It is possible to compress in HD at 1 Mbps. Compression artifacts almost disappears, but after the licensing scheme related problems (see below what I wrote about one year ago), there is a main question: the match between DASH and HEVC does not convince me a lot. In HEVC disappears the I frames but in order to break the file in chops for DASH needs, we must introduce artificial (not video related) break points (say every 5 seconds) to be able to switch in sync for bandwidth adaptation.

The DASH playlist file (officially .mpd) may contains 10 references to many audio and video resolutions. It means that you may pass from a 45 GB of source MXF file to 10 GB hevc file set. The providers of compression engines and storage are happy because they sell their services or systems on the pound, but I'm asking why do not apply chromatic and spatial resolution scalability?

To understand what is hevc scalability extension, read this article SHVC, the Scalable Extensions of HEVC, and Its Applications from ZTE corp (Shenzen, PRC) website.
Practically with scalable extensions instead of many versions of the same content encoded at different bitrate and size, are produced one basic level and some enhancements that adds informations. These enhancements may be transmitted though a DASH approach. Since you're in, read also this article about multilayering in HEVC, from the same source.

The above picture (from Multi-Layer Extension of the High Efficiency Video Coding (HEVC) Standard, same source of the former) sketches an example SHVC bitstream of spatial scalability with two layers, one base (BL) of lower resolution, and one (here, only one) enhancement layer (EL), a delta toward a higher resolution. You must consider that since in HEVC disappears the Group of Picture (GoP) concept as it was until h264 (so IBP frames do not exist anymore), any tile and/or slice in which the images sequence is decomposed has its own history and evolution. The sense is that: instead of switching between different resolution and bitrates files, the receiver get a base layer and many deltas.

Licensing of HEVC

It may be extremely interesting to read (and download) the HEVC licensing scheme from the HEVC advance, consider this website and take a look to the frequently updated licence section.
At the moment I do not know about real broadcasting test of HEVC, despite the marketing efforts. My biggest concern is related to the potential bandwidth of a transport stream broadcasted by air, cable or satellite.
The quality vs bitrate of hevc is really asthonishing, but its lack of GoP do not marry with conventional wave transmitting way such as transport stream or the DASH which segmentation is at the moment GoP prone (I mean: breaking in segment before an I-frame works better). The test I'm conducting on (360p24 and 720p24 show a high sensitivity to the bandwidth characteristics: if your connection is really broadband you'll never experience any problem... otherwise...

In february 2015 the availability of open source HEVC codec (High Efficiency Video Compression, known also as h265) means it is ready to be used by all us.

To read/download the standard reach the ITU website and select the latest available version (as of writing, on may 23rd, the latest release of april 2015 was still not available). All the ITU standards are downloadable for free in pdf format. It is extremely valuable that standards are made public at no cost. For media industries the most known are h262 (mpeg2) and h264 (avc). Please consider how all the international bodies that sell the standards damage the interoperability and the progress of technology, forbidding an easy access the reference documents to the interested audience.

The more than 500 pages of the h265 standard may be too complex at first sight.
For basic informations you may read these Wikipedia articles about the h265 standard or its tiers and levels (the profiles and levels of former MPEG standards).

something already seen

It is terrible, but after any technological risks HEVC might suffer, it seems that a number of lawyers are trying to assault this new train of technology before of its roll out

HEVC Advance produced in april last year a pricelist (officially Patent Pool pricing) updated in december in reaction of which initiative of april and december 2015 has been founded the Alliance for open media (a joint initiative of Amazon, Cisco, Google, Intel, Microsoft, Mozilla and Netflix) to create a new, royalty-free, open-source video compression format.

Last arrives the initiatives of MPEG LA (that literally killed MPEG4 in 2001) that later than other aggressive colleagues, define a specific new initiative).

What do they want to do? A proprietary open standard like VPn ?
Doesn't MPEG story teach anything to this people

At the moment I'm still trying to understand how HEVC is compatible with dynamic streaming (excluding a simpler profile enabling something like a GOP aligned segmentation) which would vanify a lot of compression gains. Even the naive way of streaming (what I'm using above) suffer of bandwidth fluctuation, but the quality gains from the algorithm.

Now these Lawyers-standards-killers (which performance we were already able to understand in 2001) could now kill even HEVC.
I hope not.

interesting articles

My voice

I remember in 1989 when the first MPEG1 standard papers comes out. A plenty of time passed by, but we must not forget it has been the first brick (even a stone: think to mp3 success!) that affected the technology of media as never before.

I was in. Maybe you could be interested to read A lot of passes have been done...

And today, being HEVC an hot subject, I've not been able to refrain me from writing down something:

embedded 360p24 HEVC embedded html page (february 2015)
It requires videolan VLC player version 2.2.0 (or greater) to be decoded. VLC is available in LGPL from videolan website.
Video embedding is not performed on smartphones for which browsers plug-ins have not been released (and probably will never done).
Smartphones - after installing VLC for android of iOS - may access to the stream http://www.iginomanfre.it/x70_hevc_300

embedded 720p24 HEVC embedded html page (february 2015)
This reproduction requires an hardware base with at least powerful as a Core2duo or a quadricore ARM on http://www.iginomanfre.it/x70_hevc_1200

Before (CPU load at 15%) and after starting the 1.2 Mbps 720p24 stream reproduction on my core2duo laptop

Welcome HEVC (may 2015)

I wrote this post three months later the former ones in which I published two embedded HEVC videos.

HEVC quality is asthonishing (take a look to my 300 kbps SD video), and any enhancement is welcome.

The first question is How much welcome?

Yes, because the entropy reduction of the HEVC is so high that any small impulsive bottleneck in ip distribution pipe may destroy a plenty of unreplaceable information, affecting a many coding units in their slices and/or tiles grouping.
In terms of viewing it means a gray/green stripes across the screen, and the probability of this increases at the size and the framerate increasing.
My samples are basic: a small 360p30 and a bigger 720p30 , but HEVC will reach 8k at high refresh rate (up to 300 Hz, because - in order to avoid sliding - increasing the size requires a faster frame speed).
This can be recovered copying the segments to the clients (as it happens in ordinary HLS streaming or DASH) but it makes mandatory the usage of FEC (Forward Error Correction) in unidirectional streaming such as plain UDP or satellite broadcasting.
This FEC can vanishes a lot of compression savings and require a delay.
So, the delay up to a couple of seconds between DTT and HLS delivery will be required still in the future.

Consequences of Moore law

Again, How much welcome?.

In broadcasting HEVC has been long awaited as the solution for bandwidth crowding, to deliver more HD channels with the SD bandwidth.
But the above mentioned more complexity imply the replacement/introduction of the decoder because the former one do not perform HEVC decoding in realtime or at all.
This could not be a problem in proprietary or brand new delivery platform (such as pay-tv) but at a cost for the broadcaster or for the consumer.
And - we know - in these times of crysis, savings more than long RoI (Return of Investment) expenses are welcome...
Despite Mr. Draghi is printing money almost free, there is not a plenty of money to invest...

In free to air delivery, satellite or DTT, HEVC will not be adopted easily because it could affect the share: the greater part of the receiver are still limited to SD MPEG2 decoding.

So, who will pay? I would not be negative, so I refrain to continue....

In any case, as the story should teach us, nothing else than a standard can find a wide market success: see the rise and fall of all non-standard (proprietary) compression schemes, even last Microsoft VCx or Google VPx.
As usual a plenty of studies has been done and will be carried out (e.g. this comparison between HEVC, VP9 and AVC, but all the honest and independent professional operators will choose nothing, absolutely nothing else than a standard.

back

Nothing is free

Listening the Telco's advertisments our homes should be surrounded by fiberoptics and multimegabit-per-second last miles.
This is partially true, at this can be tested through these pages.

The way in which this server transmits the stream is really live, without any possibility of local cashing, thus enhancing the drawbacks of any delivery inconvenience.
As known, the reduction of the information entropy to squeeze the bitrate, makes the stream highly sensible to the unavailability even of small but significant portions of information.
This may affect the quality of experience.
It can be felt comparing the reception of the same stream at different bitrate and size, at 3-400 Kbps and 1500 Kbps, and -- as recalled above -- the bitrate is tightly required.
In h265 to reach level of compression higher than h264, the concept of Group of Picture (GoP) disappears, replaced by the Coding Unit (see below).
This extension of the single Coding Unit make the stream extremely sensible to any small lack. In this case, if the available bandwidth is lower than 1.8 Mbps there is the risk to get images like these below



These images from a Vodafone ADSL (not fiber backed) at my home. of 1.5 Mbps stream.

To avoid this side effect you need to add or enforce the Forward Error Correction (FEC) to the Transport Stream as done in broadcast transmissions (such as DVB), thus partly vanishing the further compression obtained. Another strategy is that of distributing the spikes of bandwidth excess requirements on the entire stream. But increase the latency and make this approach not suitable for live events.

The advantage of transferring slices of the file to the client, that avoid such kind of problems in h264, in h265 becomes more dangerous: the potential lack of reference frame for a longer time than h264 makes more critical the splitting of the movie as done in DASH or HLS delivery.

Squeeze, squeeze always squeeze more

H265 means progressive HD at less than 3 Mbps. It introduces a lot of news. It supersede the concept of GoP and macroblock dividing the frame in slices and/or tiles (rectangular) with Coding Tree Unit (CTU) divided in Coding Units (CU) after the motion estimation. The Coding Unit (now up to 64 pixel) which is the replacement of macroblock but in h265 any CU has its own evolution and story, while until h264 it used to work at frame level. CTUs are grouped in Slices (any number of CTUs) and/or Tiles (rectangular) depending on their temporal and spatial evolution.

To understand something about how h265 works you can get something more readable from Vcodex articles An introduction to High Efficiency Video Coding or its full version (that require a login). Finally you can download the officila ITU/IEC 23008-2 standard in pdf free from ITU (quite tricky but complete).

If you're going to evaluate the hevc quality, you must remember that it is much more complex to decode than h264. Hevc is only progressive (but we were already accustomed to deal with progressive videos on the web): the problem is related to the decompression algorithm that is about thrice complex than h264.

This is the load of the decompression of 720p stretched to full screen on my laptop: about the 80%.

My dual core laptop, quietly able to decode progressive HD in h264, exhibit its inadequacy to decode 720p hevc. If the browser is not the only window open, the entire computational power can be easily drained.

Click here if the reproduction is jerky (processor power or network conditions.

640x360 progressive hevc stream

The stream embedded below is compressed in HEVC (High Efficiency Video Compression), known also as h265.
In order to be more decodable by the greater part of computers, it is only 640x360 pixel (one quarter of the original size).
The video is encoded at 300 Kbps plus 192Kbps of mp3 stereo audio all wrapped in a DVB transport stream
Click here to see the original 720p. Click here to know something more about the unicast streaming I'm using.

Beware, on mobile phones the embed area is empty because no VLC plug-in is availabile. On smartphone you must recall directly the source stream http://iginomanfre.it/x70_hevc_300. but depending on the state of the server, this stream could not be available

To be viewed is required the VLC 2.2.0 active-x browser plug-in, freely downloadable from www.videolan.org.
By default the active-x plug-in is installed. but beware: the former release (2.1.5) did not support h265, so after the upgrade is better to reboot the browser.

It has been encoded using VLC 2.2.0 that apply x265 APIs from the FFmpeg initiative.

I got this video produced by Sony and shooted with a PXW-X70 camera.

H265 means progressive HD at less than 3 Mbps. It introduces a lot of news. It supersede the concepts of GoP and macroblocks dividing the frame in slices and/or tiles (rectangular) with Coding Tree Unit (CTU) divided in Coding Units (CU) after the motion estimation, each one with its own history and evolution. The Coding Unit (now up to 64 pixel) which is the replacement of macroblock but in h265 any CU has its own evolution and story, while until h264 it used to work at frame level. CTUs are grouped in Slices (any number of CTUs) and/or Tiles (rectangular) depending on their temporal and spatial evolution.

To read something about how h265 works you you can download from Vcodex website the article An introduction to High Efficiency Video Coding or its full version (this download requires the registration). Finally you can download the official ITU/IEC 23008-2 standard in pdf free from ITU (quite tricky but complete).

If you're going to evaluate the hevc quality, you must remember that it is much more complex to decode than h264. Hevc is only progressive (but we were already accustomed to deal with progressive videos on the web): the problem is related to the decompression algorithm that is about thrice complex than h264.

The performance of my laptop deconding the stream embedded in this page are quite acceptable (45%).

This page has been set up because my dual core x86 laptop (as all its class x86 processor), quietly able to decode progressive HD in h264, exhibit its inadequacy to decode 720p hevc. If the browser must share the power with olter tasks, the entire computational power can be easily be unsufficient.
The decompression of hevc can easily be out of the capability of former generation processors: for this reason this page include a smaller version of the video (640px360).
Nevertheless, if you enlarge full screen the received video (probably at least doubling its size) you can feel the quality of this compression scheme

But also the constance of network features can be unsufficient: a greater compression means an higher reduction of the redundance so a heavily squeezed stream could not be suitable for noisy connection excluding the usage of a wrapper with an efficient error correcting code (that vanishes the compression savings). In this case it to save computational power is useless to reduce the video presentation windows size, because before zooming out, any frame must be correctly decompressed.
In hevc any small part of the image has its own story: any slice (group of macroblocs, which in hevc are no more square) has its story and evolution. The GoP almost disappears.
It means that if the decoding cannot carried out within the presentation timestamp, very often the damages strikes much longer than h264.

As expected the compression is extremely computing intensive: on my core2due 2 GHz the compression of its 8 minutes takes about 3 hours.
The wrapper is DVB transport stream, but because in h265 the concept of GoP is quite far, in case of lost of information gray portions of image strike the video for few seconds.

The source stream can be recalled directly as proxed by apache as http://iginomanfre.it/x70_hevc_300.

mediainfo analysis

apropos 4k

Other things are coming, 4k (4:2:0) with source downloaded from the web... but the time to compress them on my small core2duo is terrible.
Not only, but in july 2015 VLC stopped to compress in hevc with x265 library.
No problem, I can use ffmpeg, the open source software which developed the library. But there are few problems about which I'm investigating, not only the speed.

4k e 8k: what's the worth of this high resolution race?

The 1602 façade of Carlo Maderno is 114,69 wide by 45,44 meters tall (from wikipedia) so the pitch of the projection done at the jubilaeum opening night show has been 1.4 cm, one pixel every 1.4 centimeter



Consider that scanning an A4 sheet (21 by 29.7 cm) at 300 dpi (dot per inch, about 12 pixel per millimeter). That sheet landscape oriented is a 3K (3507 pixels).
Projecting the smallest "8k" screen (7680x4320) on a 4 mm pitch professional LED composable display (used in theatrical background) generate 30.72 wide by 17.28 meters tall image. But at home, do we need of such sizes ?
The market continously requires us to buy wider and wider screens.
The following table shows the sizes in mm and the optical viewing distances of screens by diagolan inches sizes



A 100 inches screen hosting true 8k resolution of 2.21 by 1.24 meters, it means a resolution if about 36 dots per centimeter, 90 dot per inch, about 4 dots per millimeter.
Our visual acuity is about half degree: at 3.5 meter it is about few millemeters.

When in summer 2020 we went to buy a new flat screen tv (a 4k) the selling person told us this screen technology is much much poorer than the other [the nanoled tech]: it has a led every 8 pixel.
I made a quick count: about 2000 pixels on 80 cms, it means that you could notice luminosity gradient on squares of 4 mm. But if this is true for OLED where coloured light is emitted pixel per pixel (but OLED screen suffers other problems) and partially for nanoled lecnologies, the light Luminosity behind the LCD screen does not changes.

Consumism, the soul of commerce..

Welcome to HEVC thread

And now we must wait JVET (may 2018)

JVET stays for Joint Video Exploration Team, we must become familiar with this acronym as we did with hevc or simpler h265 few years ago.
JVET, is the next chapter the ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11 team is planning to squeeze video.
These webpages from ITU website and from Fraunhofer are maybe more detailed.

The meetings of VCEG (Video Coding Expert Group) started in october 2015, aside the Geneva Lake, when most of us just hear something of hevc.
Now, as usual, there is reference a software for the JVET group, called JEM (Joint Exploration Model) which probably let us see the stars....

The page all meetings of the JVET document management system hold by University of Sud Paris lists the documents divided by the meetings related to JVET (the rest of the site - as the draft standard - seems quite in progress): but going back of about 30 years, how many would spent a cent for mpeg?

As it is written in a paper of July 2017 but diffused in the Macau meeting :

For many applications, compression efficiency is the most important property of a future video coding standard. A substantial improvement in compression efficiency compared to HEVC Main Profile is required for the target application(s); at no point of the entire bit rate range shall it be worse than existing standard(s). 30% bitrate reduction for the same perceptual quality is sufficient for some important use-cases and may justify a future video coding standard. Other use-cases may require higher bit-rate reductions such as 50%.

We all must stay Tuned!

Darkening the welcome (january 2017)

About 20 years ago, video on the web was all but diffused as today: Youtube did not exist, but more important, to stream something it was required to produce at least three files compressed in three proprietary similar but mutually uncompatible compression schemes (quicktime, windows media and real video).

In these years we passed through flash, mpeg4, dynamic streaming, h264, DASH and last h265. Recently I've worked on the catalogue of TIM vision to address the contents to the many profiles to be compressed in h265 not exactly in cloud (it could be named how we can get all the inconveniences of cloud, as you can imagine, it's a long story, not to be dealt now).

h265 confirms an asthonishing compression scheme. It is possible to compress in HD at 1 Mbps. Compression artifacts almost disappears, but after the licensing scheme related problems (see below what I wrote about one year ago), there is a main question: the match between DASH and HEVC does not convince me a lot. In HEVC disappears the I frames but in order to break the file in chops for DASH needs, we must introduce artificial (not video related) break points (say every 5 seconds) to be able to switch in sync for bandwidth adaptation.

The DASH playlist file (officially .mpd) may contains 10 references to many audio and video resolutions. It means that you may pass from a 45 GB of source MXF file to 10 GB hevc file set. The providers of compression engines and storage are happy because they sell their services or systems on the pound, but I'm asking why do not apply chromatic and spatial resolution scalability?

To understand what is hevc scalability extension, read this article SHVC, the Scalable Extensions of HEVC, and Its Applications from ZTE corp (Shenzen, PRC) website.
Practically with scalable extensions instead of many versions of the same content encoded at different bitrate and size, are produced one basic level and some enhancements that adds informations. These enhancements may be transmitted though a DASH approach. Since you're in, read also this article about multilayering in HEVC, from the same source.

The above picture (from Multi-Layer Extension of the High Efficiency Video Coding (HEVC) Standard, same source of the former) sketches an example SHVC bitstream of spatial scalability with two layers, one base (BL) of lower resolution, and one (here, only one) enhancement layer (EL), a delta toward a higher resolution. You must consider that since in HEVC disappears the Group of Picture (GoP) concept as it was until h264 (so IBP frames do not exist anymore), any tile and/or slice in which the images sequence is decomposed has its own history and evolution. The sense is that: instead of switching between different resolution and bitrates files, the receiver get a base layer and many deltas.

Licensing of HEVC

It may be extremely interesting to read (and download) the HEVC licensing scheme from the HEVC advance, consider this website and take a look to the frequently updated licence section.
At the moment I do not know about real broadcasting test of HEVC, despite the marketing efforts. My biggest concern is related to the potential bandwidth of a transport stream broadcasted by air, cable or satellite.
The quality vs bitrate of hevc is really asthonishing, but its lack of GoP do not marry with conventional wave transmitting way such as transport stream or the DASH which segmentation is at the moment GoP prone (I mean: breaking in segment before an I-frame works better). The test I'm conducting on (360p24 and 720p24 show a high sensitivity to the bandwidth characteristics: if your connection is really broadband you'll never experience any problem... otherwise...

In february 2015 the availability of open source HEVC codec (High Efficiency Video Compression, known also as h265) means it is ready to be used by all us.

To read/download the standard reach the ITU website and select the latest available version (as of writing, on may 23rd, the latest release of april 2015 was still not available). All the ITU standards are downloadable for free in pdf format. It is extremely valuable that standards are made public at no cost. For media industries the most known are h262 (mpeg2) and h264 (avc). Please consider how all the international bodies that sell the standards damage the interoperability and the progress of technology, forbidding an easy access the reference documents to the interested audience.

The more than 500 pages of the h265 standard may be too complex at first sight.
For basic informations you may read these Wikipedia articles about the h265 standard or its tiers and levels (the profiles and levels of former MPEG standards).

something already seen

It is terrible, but after any technological risks HEVC might suffer, it seems that a number of lawyers are trying to assault this new train of technology before of its roll out

HEVC Advance produced in april last year a pricelist (officially Patent Pool pricing) updated in december in reaction of which initiative of april and december 2015 has been founded the Alliance for open media (a joint initiative of Amazon, Cisco, Google, Intel, Microsoft, Mozilla and Netflix) to create a new, royalty-free, open-source video compression format.

Last arrives the initiatives of MPEG LA (that literally killed MPEG4 in 2001) that later than other aggressive colleagues, define a specific new initiative).

What do they want to do? A proprietary open standard like VPn ?
Doesn't MPEG story teach anything to this people

At the moment I'm still trying to understand how HEVC is compatible with dynamic streaming (excluding a simpler profile enabling something like a GOP aligned segmentation) which would vanify a lot of compression gains. Even the naive way of streaming (what I'm using above) suffer of bandwidth fluctuation, but the quality gains from the algorithm.

Now these Lawyers-standards-killers (which performance we were already able to understand in 2001) could now kill even HEVC.
I hope not.

interesting articles

My voice

I remember in 1989 when the first MPEG1 standard papers comes out. A plenty of time passed by, but we must not forget it has been the first brick (even a stone: think to mp3 success!) that affected the technology of media as never before.

I was in. Maybe you could be interested to read A lot of passes have been done...

And today, being HEVC an hot subject, I've not been able to refrain me from writing down something:

embedded 360p24 HEVC embedded html page (february 2015)
It requires videolan VLC player version 2.2.0 (or greater) to be decoded. VLC is available in LGPL from videolan website.
Video embedding is not performed on smartphones for which browsers plug-ins have not been released (and probably will never done).
Smartphones - after installing VLC for android of iOS - may access to the stream http://www.iginomanfre.it/x70_hevc_300

embedded 720p24 HEVC embedded html page (february 2015)
This reproduction requires an hardware base with at least powerful as a Core2duo or a quadricore ARM on http://www.iginomanfre.it/x70_hevc_1200

Before (CPU load at 15%) and after starting the 1.2 Mbps 720p24 stream reproduction on my core2duo laptop

A couple of months after considerations (may 2015)

Further consideration of November 2015

Other things are coming, 4k (4:2:0) with source downloaded from the web... but the time to compress them on my small core2duo is terrible.
Not only, but in july 2015 VLC stopped to compress in hevc with x265 library.
No problem, I can use ffmpeg, the open source software which developed the library. But there are few problems about which I'm investigating, not only the speed.

4k e 8k: what's the worth of this high resolution race?

The 1602 façade of Carlo Maderno is 114,69 wide by 45,44 meters tall (from wikipedia) so the pitch of the projection done at the jubilaeum opening night show has been 1.4 cm, one pixel every 1.4 centimeter



Consider that scanning an A4 sheet (21 by 29.7 cm) at 300 dpi (dot per inch, about 12 pixel per millimeter). That sheet landscape oriented is a 3K (3507 pixels).
Projecting the smallest "8k" screen (7680x4320) on a 4 mm pitch professional LED composable display (used in theatrical background) generate 30.72 wide by 17.28 meters tall image. But at home, do we need of such sizes ?
The market continously requires us to buy wider and wider screens.
The following table shows the sizes in mm and the optical viewing distances of screens by diagolan inches sizes



A 100 inches screen hosting true 8k resolution of 2.21 by 1.24 meters, it means a resolution if about 36 dots per centimeter, 90 dot per inch, about 4 dots per millimeter.
Our visual acuity is about half degree: at 3.5 meter it is about few millemeters.

When in summer 2020 we went to buy a new flat screen tv (a 4k) the selling person told us this screen technology is much much poorer than the other [the nanoled tech]: it has a led every 8 pixel.
I made a quick count: about 2000 pixels on 80 cms, it means that you could notice luminosity gradient on squares of 4 mm. But if this is true for OLED where coloured light is emitted pixel per pixel (but OLED screen suffers other problems) and partially for nanoled lecnologies, the light Luminosity behind the LCD screen does not changes.

Consumism, the soul of commerce..

A lot of passes have been done...

I remember in 1993-95, to compress in AVI with Radius Cinepack codec or the Intel Indeo 3.2 compressors from a PAL signal precropped to CIF format (352x288 pixels) , running on a 486 or one of the first pentium based PC's (the maximum available at the time), required an entire day (23 hours). After all the output quality was very poor if compared to today's codecs. The audio has been compressed in linear PCM with a sampling rate of 11025 KHz because at that time mpeg 1 layer 2 -- despite at that time it would be already available -- was correctly played only by dedicated hardware.

If you want you may download to play a small video (the "credits", the people that worked on Multimedia 2 go), 2 minutes long I've found on the original CD we made, compressed in Intel Indeo 3.2 (19.6 MB), in current h264 with mp3 audio (about 3.2 MB) and current h264 with aac audio (about 2.4 MB).
Expecially the first version, a quite big file, compressed with a very old codec, could be reproduced only by VLC (despite it should be playable by default by Windows), and in any case could be good to download it before through the right mouse click and "save as".
When I tested this page, I remained quite surprised to see that the entire 2 minute video, compressed in h264, was played immediately by mozilla firefox, not - as I though - through VLC after it had been choosed as default opener of mp4 files. Evidently the browser itself in a way similar to what required by HTML5 compliancy, can decode those file (they are not stream, but file seen in progressive download).
It is all but a curious note. Html5 compliancy is a big problem, as it has been interpreted by Google Chrome: the management of video compressions cannot be performedthrough external plug-ins, but must be performed by the browser itself.
Mobile phones' browsers do not use plug-ins while workstations ones allow them. But the new releases of Chrome don't accept VLC plug-in as dangerous for navigation safety.

Comparisons between the three version of the same video (mediainfo)
:

General
Filename	H:\video\Multimedia 2 Go people (19950222).avi (not downloadable because seen unsafe by many browsers)	H:\video\Multimedia 2 Go people (19950222)_a.mp4	H:\video\Multimedia 2 Go people (19950222)_d.mp4
Format	AVI, Audio Video Interleave, rec	MPEG-4, Base Media, isom	MPEG-4, Base Media, isom
File size	19.1 MiB	3.16 MiB	2.38 MiB
Duration	2mn 7s	2mn 7s	2mn 7s
Overall bit rate	1 257 Kbps	208 Kbps	157 Kbps
Video
ID	0	1	1
Format, Codec, Version/Profile/Level	Indeo 3, IV32, Intel Indeo Video 3.2	AVC, Advanced Video Coding, High@L1.3	AVC, Advanced Video Coding, High@L1.3
Details		CABAC, Reframes=4	CABAC, Reframes=4
Width, Display Aspect Ratio, Frame Rate	320x240, 4:3, 25 fps	320x240, 4:3, 25 fps	320x240, 4:3, 25 fps
Frame Rate	25 fps	variable: mean 24.247 fps, min 6.250 fps, max 25.000 fps	variable: mean 24.247 fps, min 6.250 fps, max 25.000 fps
Bits/(Pixel*Frame)	0.573	0.081	0.054
Color space, Chroma subsampling, Bit Depth, Scan	Y'UV, 4:2:0, Progressive	YUV, 4:2:0, 8bit, Progressive	YUV, 4:2:0, 8bit, Progressive
Stream size	16.8 MiB (88%)	2.22 MiB (70%)	1.48 MiB (62%)
Writing Library		x264 core 146 r2538 121396c	x264 core 146 r2538 121396c
Details		cabac=1, ref=3, deblock=1:0:0, analyse=0x3:0x133, me=hex, subme=7, psy=1, psy_rd=1.00:0.00, mixed_ref=1, me_range=16, chroma_me=1, trellis=1, 8x8dct=1, cqm=0, deadzone=21,11, fast_pskip=1, chroma_qp_offset=-2, threads=3, lookahead_threads=1, sliced_threads=0, nr=0, decimate=1, interlaced=0, bluray_compat=0, constrained_intra=0, bframes=3, b_pyramid=2, b_adapt=1, b_bias=0, direct=1, weightb=1, open_gop=0, weightp=2, keyint=250, keyint_min=25, scenecut=40, intra_refresh=0, rc_lookahead=40, rc=2pass, mbtree=1, bitrate=150, ratetol=1.0, qcomp=0.60, qpmin=10, qpmax=51, qpstep=4, cplxblur=20.0, qblur=0.5, ip_ratio=1.40, aq=1:1.00
Audio
ID	1	2	2
Format, Endianness, Sign, Codec ID	PCM, Little, Unsigned, 1	MPEG Audio, Version 1, Layer 3, 6B	AAC (lav), Advanced Audio Codec LC, 40
Bitrate	88.2 Kbps	56.0 Kbps	50.8 Kbps (max 56 Kbps)
Bitrate mode, Sampling rate, channels	Constant, 11.025 KHz, 1 channel	Constant, 48.0 KHz, 2 channels	Constant, 48.0 KHz, 2 channels
Alignement, interleave duration	Aligned on interleaves, 40 ms (1.00 video frame)
Stream Size	1.34 MiB (7%)	872 KiB (27%)	791 KiB (32%)

Un solo modo di streammare Oggi e' praticamente impossibile inserire un video in una webpage html se il video non e' codificato in un formato direttamente supportato dal browser perche' i piu' usati tra questi non supportano piu' plug-in video esterni. Fin dagli albori dell'html5 lo scopo principale dell'W3C e'stato quello di ripulire il codice html. In realta' questa semplificazione ha portato alla necessita' di integrare l'html base con chiamate a decodificatori esterni. Esattamente come si faceva prima con il tag object ed i plug-in esterni. Tra le molte istruzioni deprecate in html5 ci sono gli oggetti correlati alla architettura NPAPI derivata da Netscape. A causa della fine del supporto dei plug-in NPAPI da parte di Firefox, Chrome e Opera, utilizzando questi browser le pagine web che incorporano video che ho scritto finora non lo includeranno in corso testo. Finora, per la indisponibilita' di plug-in, sugli smartphone le mie pagine non mostravano video in corso testo. Era comunque possibile richiamare i flussi con applicazioni come VLC utilizzando la URL dell stream. Al momento in ho scritto inizialmente queste righe (4 maggio 2017) l'unico modo di continuare a vedere le mie pagine con il video in corso testo e' usare Apple Safari (nell'ultima versione per Windows, ma ora non piu' supportata da Apple) perche' nel frattempo anche Microsoft Internet Explorer non lo supporta piu'. Midori e' un possibile browser alternatico, ma non sembra una cosa realmente proponibile. Una discussione completa relativa a Firefox puo' essere trovata in questa pagina ufficiale di mozilla firefox.	Only one way of Streaming Today it is practically impossible to embed video in webpage if video is not encoded in formats directly supported by the browser because the most used ones does not support any more plug-ins Since the beginning of html5 the main goal of W3C has been to clean the html. Really this semplification brought to the need of integrate basic html with call to external decoders. Exactly as did before with object tag and external plug-ins. Between the many deprecated instructions in html5 there are the usage of objects related to the NPAPI architecture derived from Netscape. Due to the end of support of NPAPI plug-ins by Firefox, Chrome and Opera, using these browsers the webpages that embed video I wrote up to now will not show any more embedded video within text. Until now I used to stream with VLC and play the video with an external call vlc plug-in, and for this reason, due to the lack of plug-ins, on the smartphones my web pages did not show text with embedded video. It was anyhow possibile to recall the streams through applications such as VLC using the URL of the stream. Since I wrote initially this page (may 4th 2017) the only way to continue to see the webpages embedding video with plug-ins is Apple Safari (in its last windows available version but no more supported by Apple) because in the meantime Microsoft Internet Explorer also do not support it. Midori is a possible alternative browser, but it does not seem a real alternative. A complete discussion about firefox can be found in this official mozilla firefox page.
I browser con il tag video non riproducono l'hevc ma solo l'h264 o il webm. Di seguito, usando un iframe provo ad invocare un player esterno per riprodurre un hls contentente elementary stream hevc:	With video tag the browsers are unable to reproduce hevc but only h264 and webm. In the next I try using an iframe to call an external player to reproduce an hls containing hevc elementary stream:
<iframe width="640" height="360" seamless src="http://iginomanfre.it/hls7/hls7.m3u8" frameborder="1" allowfullscreen> </iframe> Now the automatic start is commented, it does not bory your browsing any more Ora ho commentato la partenza automatica dell'iframe, non ti infastidira' piu'
Per ulteriori informazioni dai una occhiata a questo file: e' relativo all'hls di un wrapper mpeg4 con elementary stream h264, ma e' la stessa cosa Se qualcosa va storto, prima di mandarmi a quel paese, prova ad aprire direttamente http://iginomanfre.it/hls7/hls7.m3u8 con vlc (versione 2.2.6 o successiva): apri flusso...	For further informations take a look to this file: it is related to the hel of a mpeg4 wrapper containing h264 elementary stream, but it is the same thing. If something goes bad, before damning me, please try to recall directly http://iginomanfre.it/hls7/hls7.m3u8 with vlc (version 2.2.6 or later): open stream...
Maybe can be interesting to browse this article where may be compared the two ways of streaming
In realta' non c'e' nessuno che proibisce nulla a nessunaltro: puoi stream-are come vuoi ma il progetto della tua pagina deve accordarsi con le possibilita' rese disponibili dai browser. Quindi - se tu vuoi usare uno dei piu' usati (oserei dire standard) - devi pensare la pagina come loro ti permettono.	Really no-one forbids anything to anyother: you can stream as you want but your page design must match with the possibilities made available by the browsers, then - if you want use one of the most used standard browser - you must conceive the page as they let you.
La nuova release 52.0 di FireFox non supporta piu' plug-ins (a parte Flash, Silverlight, Java, Acrobat) (VLC Q&A). Di conseguenza, di che risorse pensi avremmo bisogno di raccogliere per sviluppare un plug-in affidabile sia per Chrome che per Firefox? Io penso che lo dovremmo lanciare! Il plugin e' un importante elemento di VLC. Perdere i plug.in per Chrome e' stato duro, ma ora perdere anche quello per Firefox e' stato . VLC e' un grande esempio di comunita' di sviluppatori che deve essere mantenuta e a cui non deve poter perdere componenti come i plugin. Penso al dispiacere per tutti gli sviluppatori. (VLC Q&A,2).	The new Release 52.0 of FireFox is dropping support for plug-ins (except for Flash. Silverlight, Java, Acrobat) (VLC Q&A). As a ball park, what funding do you think will be needed to be raised to ensure mature plugins for both Chrome and Firefox? I think we should we crowd fund this! The plugin is an important element of VLC. Losing the Chrome plugin was difficult and now to lose Firefox is . VLC is a great example of a community developed app that must be maintained and not lose components such as the plugin. I felt the pain of all the original developers. (VLC Q&A,2).
This is the most diffused way to stream all around the world: Youtube like (vimeo or other are similar) Do not forget: you are allowed to exist only if you consume This video is available also in English as well in many other languages. The next video comes from Youtube, Google empire. It is embedded through the following call <iframe width="400" height="225" src="https://www.youtube.com/embed/oktdSO_J3Vc" frameborder="0" allowfullscreen> </iframe> It is played through the browser capabilities, that can play also webm. The following two videos are the same in terms of content but a completely different story.
This comes from youtube servers through the following call: <iframe width="640" height="218" src="https://www.youtube.com/embed/7FvCaQhh1Z0" frameborder="0" allowfullscreen> </iframe> Really behind this address Youtube streams this video in 7 times for formats and codecs:	This one from this server through the html following video markup <video src="../video/google_pizza.mp4" type="video/mp4" poster="../jpg/google pizza poster.jpg" width="640" height="218" controls> </video> But this one is one only file stored in that directory that apache streams on request.
Google make this video available in many formats and bitrate Google rende disponibile questo video in diversi formati e bitrate	While this one comes from this server in one only resolution and bitrate in progressive download

	At left a html5 video instruction that realize a practical old progressive download video embedded video. Video is downloaded locally before and while playing. This video is on the server, is mute is 19 minutes long and it is highly compressed in h264 (29 MB 480x270). Crosshairing the pointer two timelines are showns: the blue one is the current playing position while in gray is hown the latest downloaded point Positioning is quite fast, but in any case is not fast as HLS where every single video chunk is pointed by the metafile. Practically progressive download is the only native way to embed video by browser characteristics. <video width="480" height="270" controls> <source src="../video/tevere_200.mp4" type="video/mp4"> </video> A sinistra l'applicazione della istruzione video dell'html5 che realizza il vecchio progressive download embedded video. Il video e' scaricato localmente prima e mentre viene riprodotto. Questo video e' sul server, e' muto, dura 19 minuti, e fortemente compresso in h264 (29 MB 480x270). Attraversando il video col mouse vengono mostrate due timeline: in blu la posizione corrente, in grigio l'ultimo frame scaricato. Il posizionamento e' abbastanza veloce, ma in ogni caso non come in HLS dove ogni singolo segmentino video e' puntato dal metafile. Praticamente il progressive download e' l'unico modo nativo html di inserire video in corso testo grazie alle capacita' del browser.
Il vantaggio e' che si vede anche sul cellulare (qui sul mio note2) The advantage is that can be seen also on smartphones
Come dicevo all'inizio, in realta' nessuno impedisce nulla a nessun altro: tu puoi stream-mare come vuoi, ma la tua pagina deve accordarsi con quanto reso disponibile dai browser, quindi - se vuoi usare quelli piu' usati e standard - devi concepirla come ti e' permesso. Infatti da questo sito io sto continuando a stream-mare in mpeg2, h264 e anche h265 wrapp-ati principalmente in Transport Stream o in HLS (vedi questa lista), e questi stream possono essere visionati con un player (come media player o videolan, eventualmente ricompilati in forma di app appositamente realizzata) ma non puoi inserirli in un browser perche' questi non ammettono piu' plug-in video (salvo quelli commerciali). Infine puoi utilizzare una versione obsoleta di un browser open source che supporti ancora il plug-in video di VLC. In questa pagina utilizzo iframe per richiamare una applicazione esterna (io ho associato vlc) per aprire un video. iframe e' abbastanza pericolosa perche' puo' richiamare qualsiasi cosa, compresi malware o virus. Ma per quanto ne so - escluso il progressive download e dopo la eliminazione dei plug-in video - e' l'unico modo di richiamare un video all'interno di una pagina.	As I said at the beginning, really no-one forbids anything to anyother: you can stream as you want but your page design must match with the possibilities made available by the browsers, then - if you want use one of the most used standard browser - you must conceive the page as they let you. In fact from this site I'm continuing to stream mpeg2, h264 and even h265 wrapped mainly in transport stream or in HLS (see this list), and these stream can be loaded with a stream viewer (such as media player or videolan) or a stand alone app but you cannot see these video within a browser because no plug-in (excluding commercial ones) are any more supported for this purpose. Last you can use an obsolete version of an open source browser at the time it still support VLC video plug.in In this page I use iframe to recall an external app (I choose vlc) to open the video. iframe is quite dangerous because can recall everything, including malware or virus. But for my knowledge - excluding progressive download and after video plug-in execution - is the only way to recall a video within a page .